)

## Summary

### Why?

The build stage needs a vendor-agnostic abstraction for talking to a
Build Runner — one that fits the existing extension family (storage,
queue, conflict) and that does not have to change when the first real
backend lands. Design rationale lives in `doc/rfc/build-runner.md`.

### What?

Introduces the `BuildRunner` contract — three verbs, all keyed by an
`entity.BuildID`: `Trigger` submits a build (ordered `base` + `head`
change sets plus a free-form metadata map) and returns its ID; `Status`
fetches the current `BuildStatus` and runner-defined metadata; `Cancel`
requests cancellation. See `extension/buildrunner/build_runner.go` for
the signatures.

Highlights:

- `Trigger` takes ordered `base` (assumed-good prefix from dependency
  batches) and `head` (changes being verified) — a runner can cache or
  short-circuit a prefix it has validated before, and attribute terminal
  failures to base vs head via `BuildMetadata`.
- Build identifiers are the typed `entity.BuildID` (a lightweight
  `{ID string}` value, also the queue payload envelope) rather than a
  bare `string`, so the runner contract and the on-queue messages share
  one identifier type and the compiler distinguishes a build ID from
  other string IDs.
- `metadata` is a free-form `map[string]string` for caller-supplied
  attributes (requester, ticket ID, trace ID) the runner MAY persist or
  echo back via `Status`.
- `Trigger` and `Cancel` return promptly; `Status` MAY be lengthy.
- The `BuildStatus` enum is narrowed to `Accepted` / `Running` /
  `Succeeded` / `Failed` / `Cancelled` so every backend can map its
  native lifecycle without leaking runner-specific stages.
- `BuildMetadata` is added as a free-form map for round-tripping
  runner-defined attributes (build URL, duration, SHA, etc.).

Naming: the interface is `BuildRunner` (not `BuildManager` — the
"Manager" suffix doesn't describe what it does, and "Build" alone would
collide cognitively with `entity.Build`). The package is
`extension/buildrunner` to follow the repo convention used by
`mergechecker`, `changeprovider`, `pusher`, `counter`, and `storage`.

Implementation (noop backend, queue `PublishAfter` primitive, controller
wiring, and the poll-driven `buildsignal` loop) lands in the follow-up
PRs stacked on top of this one.

## Test Plan

- ✅ `make test` — entity/build tests pass; mock-only consumers of the
  interface compile and pass.
- ✅ `make fmt lint check-tidy check-gazelle check-mocks` — clean.
- ✅ `make build` — all targets compile.


## Stack
1. @ #175
1. #179
1. #176
1. #177

## Summary
### Why?

Wiring tests for the orchestrator's build stage need a `BuildRunner`
implementation, but real backends (BuildKite, Jenkins, etc.) won't land
until later. A noop that immediately reports success is also useful as
the local default in `make local-start` and as a best-case baseline
where every build passes.

### What?

Adds `extension/buildrunner/noop` — a `BuildRunner` that does no real
work. Every `Trigger` returns a unique `noop-<n>` build ID with no
error; every `Status` returns `BuildStatusSucceeded` with no metadata;
`Cancel` is a no-op. The atomic counter keeps IDs unique under
concurrent use.

## Test Plan
- ✅ `make test` — 36 unit tests pass, including the new
  `extension/buildrunner/noop:noop_test` (Trigger uniqueness, Status,
  Cancel, interface satisfaction).
- ✅ `make fmt lint check-tidy check-gazelle check-mocks` — clean.
- ✅ `make build` — all targets compile.

## Issues


## Stack
1. #175
1. @ #179
1. #176
1. #177